Wireless communications have enjoyed tremendous growth and permit both voice and data communications on a global scale. Indeed, WLAN access networks are currently deployed in many public places, such as airports, hotels, shopping malls, and coffee shops. The WLAN market is currently undergoing a rapid expansion and is being offered as a complementary service for mobile operators. PLMN core network operators, such as GPRS and UMTS network operators, traditionally provide access to mobile packet data services via a wide area GPRS or UMTS network. More recently, those mobile operators have also offered that mobile packet data service directly through a high capacity WLAN access network. Ideally, the mobile operators can provide the packet data service seamlessly between PLMN and WLAN.
There are several important requirements for a mobile operator's complementary WLAN service. First, the WLAN must interwork PLMN, e.g., GPRS and UMTS, established standards. GPRS and/or UMTS are used as non-limiting examples of a PLMN. Specifically, it must be possible to reuse existing GPRS/UMTS authentication mechanisms for WLAN access without degrading the security of the GPRS/UMTS network. Second, roaming must be permitted and specified between wide area cellular radio access and WLAN access networks. Significantly, roaming between different mobile operator WLANs must be supported. A WLAN access network may have a direct or an indirect relationship with one or more service networks.
FIG. 1 illustrates an access configuration where a mobile terminal (MT) 10 initially requests access via a local access network 12. Local access network 12 typically provides “hotspot” wireless connectivity for WLAN clients like the mobile terminal 10 present in its local access coverage area. The local access network 12 is connected to a home service network 14, which provides the ultimate communication service and maintains the direct relationship to the mobile terminal 10. The local access network 12 includes one or more access points 16 (e.g., radio base stations) that provide access to the communication services over the radio or wireless interface. An access router 18 is the data gateway to the Internet and/or an Intranet 13 and to the home service network 14, and it routes data between the mobile terminal 10 and the home service network 14 (although the data path between the access router 18 and the home service network 14 is not shown). The authentication, authorization, and/or accounting (AAA) server 20 is involved in performing authentication and/or authorization of the mobile terminal 10 before access to services is permitted. In this regard, AAA is used as a general term to refer to one or more of authentication, authorization, or accounting and similar operations. The AAA server 20 is also involved in accounting functions once access is permitted. The home AAA server 24 is coupled to a home subscriber server (HSS) 22, which accesses a home subscriber server database (not shown). The home AAA server 24 authenticates and authorizes the mobile terminal using authentication and authorization procedures, which are often performed using the well-known RADIUS or Diameter protocols. An information field in a RADIUS or Diameter message is in this document referred to as an “attribute” or an “AVP”, where AVP stands for “Attribute Value Pair”.
FIG. 2 illustrates how the local access network may have an indirect (i.e., via an intermediary service network) relationship with a home service network. The local access network has an association with intermediary service networks 30, 34, and 38, and each intermediary service network has its own AAA server 32, 36, and 40, respectively. But only two intermediary service networks 30 and 34 have roaming agreements with the home service network 14. Although not illustrated, there may also be a network (or even multiple networks) between the local access network and the intermediary service networks 30, 34, and 38 in the form of a “roaming consortium”.
When a UMTS/WLAN subscriber accesses a WLAN access network, the subscriber's terminal sends a network access identifier (NAI) of the subscriber to the network. An NAI is an identifier with format “name@operator-realm”, as described in, “The Network Access Identifier,” RFC 2486, January 1999. The NAI is sent using Extensible Authentication Protocol (EAP) over LAN (EAPOL). The transfer of the NAI precedes either an EAP Authentication and Key Agreement (AKA) procedure, as described in J. Arkko et al., “EAP AKA Authentication”, Internet-Draft draft-arkko-pppext-eap-aka-10.txt, or an EAP Subscriber Identity Module (SIM) procedure, as described in H. Haverinen et al., “EAP SIM Authentication”, Internet-Draft draft-haverinen-pppext-eap-sim-11.txt. The AAA client located in the WLAN AP 16 or the access router 18 (most commonly in the AP) forwards the NAI via an AAA protocol to an AAA server, (e.g., RADIUS, as described in C. Rigney et al., “Remote Authentication Dial In User Service (RADIUS)”, RFC 2865, or Diameter, as described in Pat R. Calhoun et al., “Diameter Base Protocol” RFC 3588, Pat R. Calhoun et al., “Diameter Network Access Server Application”, Internet-Draft draft-ietf-AAA-diameter-nasreq-12.txt, and Ed P. Eronen, “Diameter Extensible Authentication Protocol (EAP) Application”, draft-ietf-AAA-eap-02.txt). This is normally a default AAA server, which may be either the AAA server of the UMTS/WLAN operator or an AAA server of the WLAN network operator (if these operators are not one and the same). In the latter case, the AAA server in the WLAN network forwards the NAI to the AAA server in the subscriber's home UMTS/WLAN network via RADIUS or Diameter. The home AAA server processes the received message and performs an authentication procedure towards the mobile terminal. Subsequent AAA messages (e.g., for accounting during the session) follow the same path between the AAA client and the home AAA server, possibly via an AAA server in the WLAN network.
If a UMTS/WLAN subscriber roams into a WLAN network that has no association with the home network of the subscriber, then the subscriber is granted access only if the visited WLAN network has an association with a UMTS network that has a roaming agreement with the roaming subscriber's home UMTS network. This association may be a direct association or an indirect association via an AAA broker or proxy.
An example where the AAA communication between the visited WLAN access network and the home network of the subscriber must go through a visited UMTS network, (i.e., a UMTS network with which the home UMTS network of the subscriber has a roaming agreement), is illustrated in FIG. 2. More specifically, AAA messages sent from the AAA client to the AAA server of the visited WLAN network are then routed via the AAA server of an intermediary visited UMTS network (30 or 34) to the home AAA server 24 of the subscriber's home UMTS network 14.
A problem with this arrangement is that the AAA server 20 of the visited WLAN network 12 may have associations with multiple UMTS networks. Thus, the WLAN AAA server 20 does not know which of its associated UMTS networks has a roaming agreement with the home UMTS network 14 of the roaming subscriber. Even if the AAA server 20 of the visited WLAN network 12 did have this knowledge, the home UMTS network 14 of the subscriber may well have roaming agreements with more than one of the UMTS networks associated with the visited WLAN network 12. Because the choice of intermediary visited UMTS network is either impossible or arbitrary for the AAA server 20 of the visited WLAN network 12, the home service network 14 and/or the subscriber should be able to make the choice so that the most appropriate intermediary visited service network is selected. For example, in FIG. 2, intermediary service network 1 may be selected as the intermediary visited network, but intermediary service network 2 may be a better choice or simply the intermediary service network the subscriber prefers. In any event, intermediary service network 3 would not be chosen, because the home service network 14 does not have a roaming agreement with it.
There are several approaches to this problem. In two possible approaches, the WLAN network provides the mobile terminal with information about the service networks associated with the WLAN network. The mobile terminal then selects one of the associated service networks as its intermediary visited service network and indicates the selected network through information incorporated in an “extended NAI” or a “decorated NAI.” The format of the decorated NAI could be, for example, home-realm/name@intermediary-visited-network-realm or home-realm!name@intermediary-visited-network-realm. The AAA server of the intermediary visited service network would interpret the decorated NAI, delete the intermediary-visited-network-realm part and move the home-realm part to its normal position after the @ character and delete the slash character or exclamation mark (thus turning the decorated NAI into a regular NAI) before forwarding the AAA message (in which the decorated NAI was included) to the AAA server of the subscriber's home network. Alternatively, the AAA server of the visited WLAN network could perform this operation before sending the AAA message to the AAA server of the intermediary visited service network.
The difference between the two approaches is how the information about associated networks is conveyed to the terminal, and to a certain extent, how the decorated NAI is transferred to the AAA server of the visited WLAN network. In the first approach, the Service Set Identifier (SSID) normally broadcast or “advertised” by the WLAN APs could be modified to contain information about associated UMTS network(s). The mobile terminal could then choose to access the WLAN access network or not, and if it chooses to access the WLAN access network, the mobile terminal can supply network selection information in the decorated NAI in the EAP-Identity Response message (responding to the initial EAP-Identity Request message from the WLAN network) during the authentication procedure.
But because the size of the SSID is limited, (no more than 30 octets of data), this approach relies on the concept of virtual APs to be implemented. With the virtual AP concept, a single physical AP can implement multiple virtual APs so that several WLAN hotspot providers can share the same infrastructure. In the context of network advertising, each associated UMTS network would be represented by its own virtual AP. Each virtual AP would send its own beacon frames advertising a unique SSID that identifies the corresponding UMTS network.
In the second approach, the information about associated UMTS networks could be included in an EAP-Identity Request message, (the EAP Identity Request message format is described in L. Blunk, et al., “PPP Extensible Authentication Protocol (EAP)”, RFC 2284), from the WLAN network to the terminal. Specifically, the intermediary network information could be included after a NULL character in the Type-Data field in the EAP-Identity Request message. The EAP-Identity Request message may originate from the WLAN AP (in case it is the initial EAP-Identity Request message) or the AAA server of the visited WLAN network (in case it is a subsequent EAP-Identity Request message). In the former case, the AP includes this information in the initial EAP-Identity Request message provided that the AP, and not the access router, is the EAP authenticator. In the latter case, the AAA server of the visited WLAN network sends the information about associated UMTS networks to the terminal in a second EAP-Identity Request message only if the NAI received from the user/terminal in the response to the initial EAP-Identity Request message is not enough to route the AAA request to the home AAA server of the user. The mobile terminal could also explicitly request the AAA server of the visited WLAN network to send the network information in a second EAP-Identity Request message by providing a NAI with a dedicated request string (e.g., “Network-Info-Requested”) in the name portion of the NAI in the first EAP-Identity Response message.
These approaches are terminal-based network selection methods in that the selection of the intermediary visited service network is based on criteria available in the terminal and/or manually input from the user. Available data that can be used for this purpose (besides manual user input) include, e.g., the following USIM files: User controlled PLMN selector with Access Technology (USIM file: EFPLMNwAcT), which is a user defined PLMN priority list, Operator controlled PLMN selector with Access Technology (USIM file: EFOPLMNwACT), which is an operator defined PLMN priority list, and the Forbidden PLMNs (USIM file: EFFPLMN), which is a list of forbidden PLMNs in which roaming is not allowed (see 3 GPP TS 31.102 v6.2.0, “3rd Generation Partnership Project; Technical Specification Group Terminals; Characteristics of the USIM application (Release 6)”.
A problem with the first approach, as identified earlier, is the limited space in the SSID field, which makes it necessary to use the virtual AP concept. Using the virtual AP concept for this purpose is problematic for several reasons. The fact that each virtual AP sends its own beacon frame increases signaling overhead (in terms of resources consumed by beacons) and has substantial scaling problems. Even a few virtual APs produce beacons that consume on the order of 10% of the total AP capacity. If numerous UMTS networks, e.g., UMTS networks associated with the WLAN network via a roaming consortium, were advertised, the beacons would consume the entire AP capacity. In addition, most deployed APs do not implement the virtual AP concept, and its presence in future APs is still uncertain. Thus, numerous installed APs would have to be upgraded. Another problem is that many deployed WLAN access networks may not be in a position to change their SSID.
The second approach is also problematic. In the variant where the network information is sent in the first EAP-Identity Request message, the behavior of the APs must be modified (which is particularly undesirable considering the number of deployed APs). In the other variant, a roundtrip delay between the terminal and the AAA server in the visited WLAN network is added to the overall access delay. In addition, since some EAP implementations already use the space beyond a NULL character in the Type-Data field of the EAP-Identity Request to convey various options, there is a potential risk for interference between intermediary UMTS network information transfer and existing use of the data space.
A general problem with all of these approaches is that they require the WLAN network to be knowledgeable about all the potential intermediary UMTS networks. This may not always be the case or even possible, e.g., when there is a roaming consortium between the WLAN network and one or several of the potential intermediary UMTS networks. Thus, schemes relying on network information advertised by the WLAN network may fail in some situations. An additional problem with these approaches is that they require EAPOL to be supported in the WLAN access network, which excludes, e.g., WLAN access networks that use web-based login procedures.
These problems also impact a larger AAA message routing context. FIG. 3 shows an example network that includes a mobile terminal (MT) and a WLAN that has known routes to two roaming consortiums (RCs) RC1 and RC3 and two UMTS networks UMTS 4 and UMTS 5. In a roaming consortium (RC), multiple networks subscribe to a common roaming agreement. If a WLAN network is a member of a roaming consortium RC1, it is likely that the WLAN network is not aware of the other members including RC2 and UMTSs 1-3 and 8-9. A WLAN network is likely not a member of more than one RC. Otherwise, its realm-based AAA routing would not work properly, since it would not know to which RC to send the AAA requests. Still, to provide a general picture, assume the WLAN in the example network of FIG. 3 is a member of RC1 and RC3.
Since the WLAN network does not know what networks that are beyond RC1, RC3, UMTS3, or UMTS5, only these networks RC1, RC3, UMTS3, and UMTS5 are reasonably advertised, e.g., by announcing them via SSIDs using the virtual AP concept with multiple beacons or by EAP-based advertising. But this advertising does not include all potential intermediary 3GPP networks with which the WLAN has a roaming agreement or association. Consequently, the advertisement does not permit selection of intermediary RCs or intermediary UMTSs beyond those advertised, which in this example include RC2 and UMTSs 1-3 and 8-9.
For example, when a user accesses a WLAN access network via the user's mobile terminal, the WLAN AAA server may not know which UMTS networks can be reached through the AAA infrastructure. Therefore, selecting and indicating only one intermediary UMTS network (or the home UMTS network) may not be the best routing strategy for the user. And if the WLAN network is not aware of, and therefore, does not advertise a UMTS network that the user could use as an intermediary UMTS network (or home UMTS network), the user or the user's mobile terminal either has to select an intermediary UMTS network at random or refrain from access. In the former case the end result may well be that access is denied, making both options unsatisfactory.
Indeed, there are several possible undesirable consequences of the WLAN not knowing about viable intermediary UMTS networks including suboptimal routes and unnecessary access denial. If there are multiple AAA paths to the home network, an AAA request may well be routed through a less preferred one. First, the AAA request may be routed via an intermediary UMTS network even though the home UMTS network is reachable via a RC. Assumedly, the AAA route via the RC is preferable to the AAA route via the intermediate UMTS network, since the UMTS-WLAN interworking architecture requires that the WLAN traffic is (normally suboptimally) routed via the visited intermediary UMTS network (according to scenario 3 of the 3GPP-WLAN interworking specification), which in turn means that the intermediary UMTS network normally will keep a part of the traffic charges. For instance, if UMTS 3 is the home network, the AAA request may be routed via UMTS 4 instead of via RC1. Second, the AAA request may be routed via a certain intermediary UMTS even though more preferable potential intermediary UMTSs were reachable via a RC. For instance, if UMTS 8 is the home UMTS, the AAA request may be routed via UMTS 5, even if UMTS 3 is a more preferable intermediary UMTS network. Third, the AAA access may be denied because no route could be found, either to the home network or to a potential intermediary UMTS, even though potential intermediary UMTSs were reachable via a RC. For instance, if the home network is UMTS 9, no AAA route would be found (and access would be denied), even though UMTS 2 could act as an intermediary UMTS.
Another problem associated with AAA routing involving intermediary network preferences is related to server-initiated messages, i.e., AAA requests initiated by the home AAA server and sent in the direction of the AAA client accessed by the mobile terminal. In most cases, the messages from the home AAA server (the “downlink direction”) are sent in response to AAA messages originated from the AAA client (the “uplink direction”). In these cases, transaction information (a transaction includes a request-response message exchange) in the intermediary AAA server and the home AAA server ensures that the response message traverses the same AAA route or path (in the downlink direction) as the AAA client-initiated AAA request. However, in the case of home network-initiated AAA requests, no transaction information is present to guide the AAA message along the desired path downlink towards the AAA client
The home AAA server can store the FQDN of the target AAA client as AAA session information (a session starts with an access request by the mobile and ends when the mobile disconnects from the network or explicitly deactivates communication or when the AAA server terminates the session (e.g. because the subscriber is out of funds in his pre-paid account)) and use it for routing server initiated AAA requests, but this FQDN does not provide any information about intermediary networks. Thus, there is no way to ensure that a home network server-initiated AAA request will traverse a desired intermediary network (assuming one is available). Instead, the server-initiated request will be routed according to the regular realm-based routing principles, i.e., based on the realm and/or FQDN of the target AAA client, which may result in another route or path that does not traverse the selected intermediary network(s) is used, or that no path at all is found.
In order to facilitate the realm-based routing of AAA requests and to ensure that a route to the home network can always be found, provided that one exists, a list of potential intermediary networks, preferably sorted in priority order, is, according to the present invention, included in the AAA request. AAA proxies (or relay agents) along the route can then use this list to find a reachable intermediary network in the list, even if the initial AAA server, the WLAN AAA server, had no knowledge of any of the networks in the list. Thus, the network list enables a form of “extra loose AAA source routing” that is flexible enough to handle also complex network scenarios. The term “extra loose AAA source routing” is meant to indicate a type of source routing where the indicated intermediary networks are merely potential, selectable intermediary networks and none of the indicated intermediary networks is mandatory to traverse. The prioritized list of potential intermediary networks can be made available to the initial AAA server, the WLAN AAA server, in different ways. Two such ways are described in commonly-assigned application Ser. No. 10/960,782, entitled, “Home Network-Assisted Selection Of Intermediary Network For A Roaming Mobile Terminal”, and commonly-assigned application Ser. No. 10/960,780, entitled, “Terminal-Assisted Selection Of Intermediary Network For A Roaming Mobile Terminal”. In the former commonly-assigned application, the WLAN AAA server retrieves the list from a central AAA server, which in part is in control by the home UMTS network operator. In the latter commonly-assigned application, the WLAN AAA server receives the list from the mobile terminal.
To ensure that server initiated AAA requests traverse the same selected mandatory intermediary network(s) as the client initiated AAA requests, the realm (in the form of a fully-qualified domain name (FQDN)) of each traversed mandatory intermediary network and the host identity (in the form of a FQDN) of the corresponding traversed intermediary AAA server are recorded in a client initiated AAA request and stored in the home AAA server. Subsequently, the home AAA server can include the stored information in server initiated AAA requests and route the requests via the mandatory intermediary network(s) using a sort of realm-based (and sometimes host identity based) loose source routing mechanism. In this case, the source routing mechanism is “loose” but not “extra loose” in the sense that the server-initiated AAA request must traverse the indicated intermediary network(s) on its way to the target AAA client, but it may also traverse one or more non-indicated intermediary network(s) (in addition to the indicated one(s)).
The present invention overcomes these problems using enhanced routing of an authentication, authorization, or accounting-related (AAA) message (related to a roaming mobile terminal) between a visited network and a home service network involving intermediary service network preferences. The term “mobile terminal” as used herein, for ease of description, encompasses mobile terminal equipment, the user or subscriber of the mobile terminal, the identity of a personal entity such as a SIM-card as well as the subscription currently associated with the mobile terminal. So, for example, authorization or authentication of the mobile terminal includes authorization or authentication of the user identity and authorization or authentication of the mobile terminal. The term “service network” encompasses any type of entity that can serve subscribers or facilitate serving of subscribers by participating in authentication, authorization and/or accounting signaling, e.g., a network serving its subscribers, an intermediary network, or a roaming consortium, e.g., in the form of a AAA server.
A list is stored of one or more intermediary service networks preferred for possible use in routing an AAA message between the mobile terminal and the home service network. The list is included with the AAA message and used to select one or more intermediary service networks. A selected intermediary service network conveys the AAA request message towards the home service network. The intermediary service networks are preferably listed by priority so that the intermediary service network with a highest priority on the list can be selected first. Each intermediary service network may be identified in the list using a domain name or a fully-qualified domain name (FQDN) of an AAA server of the intermediary service network. The list may be included, for example, as one or more AAA attributes in the AAA message, or in a network access identifier (NAI) associated with the mobile terminal that is included in the AAA message.
If the AAA message is a local access network (i.e., an AAA client)—originated AAA message, then the local access network currently being accessed by the mobile terminal stores the list for routing the AAA message in a first direction towards the home service network. If the local access network knows of a route for the AAA message to the home service network, the local access network routes the AAA message towards the home service network. Otherwise, the local access network includes the list in the AAA message and sends the AAA message on to one of the intermediary service networks on the list or to a default intermediary network.
Each intermediary service network that receives the AAA message with the list determines if a route for the AAA message to the home service network is known. If a route is known, the intermediary service network routes the AAA message towards the home service network. If a route is not known, the intermediary service network sends the AAA message on to one of the intermediary service networks on the list or to a default intermediary network.
If the AAA message is a home service network-originated AAA message, then the home service network stores the intermediary service network list for routing the AAA message in a second direction towards the local access network. In order to create the list, when the AAA client originates an AAA request message routed through a selected one or more preferred intermediary service networks, each selected intermediary service network adds to the AAA request message an associated identifier. Then when the home service network receives the AAA request message, the home service network generates the list using the associated identifier(s) included by the selected one or more intermediary networks. Thereafter, when the home network wants to originate an AAA message to the local access network, the home service network uses the generated list to route the home service network-originated AAA message towards the local access network using each of the intermediary service networks included on the generated list.
Each listed intermediary service network receiving the home service network-originated AAA message routes the home service network-originated AAA message to the next intermediary service network on the list or, if there are no more intermediary service networks on the list, directly to a local access network currently serving the mobile terminal. Each listed intermediary service network preferably removes its associated identifier from the list before routing the home service network-originated AAA message directly to that local access network or before routing the home service network-originated AAA message to the next intermediary service network on the list. In one example implementation, the associated identifier may include one or both of a domain name of the intermediary network or a domain name of an AAA server of the intermediary network.